This invention relates generally to analysis of program code and, more specifically, relates to static and run-time analysis of program code.
This section is intended to provide a background or context to the invention disclosed below. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived, implemented or described. Therefore, unless otherwise explicitly indicated herein, what is described in this section is not prior art to the description in this application and is not admitted to be prior art by inclusion in this section.
Statistics on the security status of web applications are alarming. There are approximately 100,000 vulnerability reports each year, and the trend is growing. A recent IBM (International Business Machines) study has shown 40 percent of Fortune 500 web applications to be vulnerable. See International Business Machines, “Close encounters of the third kind: A look at the prevalence of client-side JavaScript vulnerabilities in web applications”, White Paper, 2010. This unfortunate situation places a high motivation on the problem of security testing of web applications.
There is a rich and diverse landscape of testing techniques with different sources of sophistication. These include, for example, the following: usage of static analysis to guide testing (see Hewlett Packard, “HP Fortify Software Security Center: Proactively Eliminate Risk in Software”, 2011); feedback-based testing based on past tests that have failed (see “XSS Analyzer Gives You 700 Million Reasons To Feel Secure”, Jul. 2, 2012); as well as testing based on fingerprinting hints (e.g., heuristic attempts to guess which frameworks and backend databases the application uses) (see “Web Application Fingerprinting”, from the Penetration Testing Lab).
A main disadvantage of all these techniques is that each testing round must complete, yielding concrete feedback (e.g., in the form of a response from the application under test), before the testing system can decide on the next step in its testing strategy. Specifically, a test that has left the testing system has a fixed, fully specified behavior, which may lead to multiple test rounds before the system converges on an appropriate test for demonstrating a vulnerability.